[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] [rt-pmc] Virgo release branding
- From: Wayne Beaton <wayne@xxxxxxxxxxx>
- Date: Wed, 13 Jul 2011 14:56:18 -0400
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11
I'm pretty sure that the EDP supports the notion. At least it provides
enough wiggle room that it could be interpreted in that way.
My primary concern is confusion in the community. My feeling is that the
Virgo project is doing a bunch of potentially confusing things. Okay...
At least two. Non-sequential version names in lieu of numbers will be
confusing. I assume that the separation within the project will use
similar non-sequential, likely-unrelated names?
Do you have a plan for keeping the different things that you're
My understanding is that bundlor is something that's useful outside of
Virgo. By keeping it in Virgo, you are excluding a large part of the
community that (a) won't think to look for it there, or (b) will assume
that it is Virgo-specific. Is it time to move that piece to Tools?
Is the "IDE Tooling" Virgo-specific?
Are the PMC meeting minutes available for review?
On 07/13/2011 10:03 AM, Glyn Normington wrote:
> Hi Wayne
> We discussed this topic at today's RT PMC call and there was a general consensus that the ability to release parts of a project without the overhead of putting those parts in subprojects would be very useful. Of course, the usual release review and IP log freezing process would be required.
> So what else do we need to consider before we can agree this approach?
> On 17 Jun 2011, at 17:09, Wayne Beaton wrote:
>> On 06/17/2011 11:58 AM, Glyn Normington wrote:
>>> I am wondering whether we'll need to put the IDE tooling, the bundlor
>>> manifest generation tool, and each of the samples in their own
>>> subprojects to give us the necessary versioning and release
>>> flexibility. It *feels* mostly like make-work, but I guess it would be
>>> easier to keep the IP logs straight that way. If, OTOH, there is a
>>> slicker solution, I'm all ears as I have better things to do than
>>> re-arrange project metadata... ;-)
>> Like I said, we're set up for projects having a single release stream,
>> so you may have to be patient with me and help me figure this out. I'd
>> rather avoid make-work as well. I'd only recommend making a separate
>> project if it makes sense for your committer base and community. At this
>> point, I don't believe that this is the case. This may change with time.
>> Had the PMC weighed in on this? They may have an opinion about the split
>> between runtimes and tools.
>> virgo-dev mailing list
> rt-pmc mailing list
The Eclipse Foundation