Furthermore, since every administrator I talk to asks me "Isn't Crowbar a
Dell-only project," I think it's a good idea to embrace the OpenCrowbar
project name.. much as SUSE is recognized by OpenSUSE, even in the press
http://linux.slashdot.org/story/13/11/19/2353236/opensuse-131-released-and-reviewed
.

Finally, there is so much documentation debt in the wiki, I'd be very happy
to just cut it loose.


On Wed, Nov 20, 2013 at 11:01 AM, Judd Maltin <j...@newgoliath.com> wrote:

> All the branching doesn't address the confusing situation for newbies who
> we are trying to attract to the project.  Since we'll be leaving a huge
> portion of the 1.x codebase behind for good and forever, I think the gains
> of making it easy for newbies to join FAR outweighs branching and cleaning
> up.
>
>
> On Wed, Nov 20, 2013 at 9:52 AM, Adam Spiers <aspi...@suse.com> wrote:
>
>> christopher_dearb...@dell.com (christopher_dearb...@dell.com) wrote:
>> > Rob,
>> >
>> > I think you misunderstood my recommendation below.  What I'm
>> > proposing is that we branch everything, including the main Crowbar
>> > repo.
>>
>> I think I'm on the same page as you here Chris, although the above
>> statement makes it sound like a much bigger deal than it actually is!
>> All the barclamp repos are already branched, so all that needs to be
>> done is to branch the main repo, and split out non-release-specific
>> stuff.  (I have been advocating for both of these actions for a long
>> time.)
>>
>> There would be NO risk of destabilising CB1, because that's exactly
>> the use case (git) branches were invented to handle in the first
>> place.
>>
>> > At this point in time, I'm not seeing the benefit of creating a new
>> > org since everything that we want done can be done with branching,
>> > which would involve creating no new repos at all, while creating a
>> > new org would create duplicate repos of every one that we have
>> > today.
>>
>> Correct.  Furthermore I have not yet heard any proposals how to
>> address the numerous concerns I raised about creating a second
>> organisation (quoted again below for reference).  On the flip side,
>> the only disadvantage I can think of caused by keeping a single org is
>> that people can't trivially choose how to be notified at per-release
>> granularity.  However this seems to be achievable via RSS:
>>
>>
>> http://stackoverflow.com/questions/7353538/setting-up-an-github-commit-rss-feed
>>
>> Hopefully we can iron this all out in 70 minutes from now.  To anyone
>> who intends to participate in the discussion, it would be very helpful
>> if you could glance over this first:
>>
>>   http://crowbar.sync.in/crowbar-repos
>>
>> > Rob Hirschfeld <rob_hirschf...@dell.com> wrote:
>> > > That's a clear +1 towards new Github Org to me.
>> >
>> > Hmm, that's not clear to me - possibly the way to go, but I think
>> > that would require a lot more thought first.  For example it raises
>> > the question of how the two organizations should be named, doubles
>> > the number of places issues can be tracked, potentially causes
>> > confusion over which wiki should be used, and which repo should host
>> > the website.  It also doubles the number of (push) access lists and
>> > subscriptions to be managed.  The plus side of that is that commit
>> > rights and notifications could be per-release ... for *now*, but
>> > only until Crowbar 3, at which point it's not at all clear what
>> > would be the right path.  A github org per release is WAY overkill.
>> >
>> > Another reasonable route is to create new repositories within the
>> > existing org.  There are pros and cons to this too.
>> >
>> > A third route is simply to break out the top-level repo (and the dev
>> > tool with it) into more sensible chunks.  That's the least invasive
>> > approach, and the one which I (and I think *probably* Victor too)
>> > had in mind when we discussed it.
>> >
>> > Whichever approach we take, we should be clear that creating a new
>> > github org or repos is not the silver bullet.  The real hard work is
>> > doing the cleanup.  That *must* include getting rid of the releases/
>> > tree.  I am absolutely convinced that the *only* way to go is to
>> > have strictly a git branch per release, with the branch names
>> > unified across all repos which contain any release-specific data, as
>> > detailed at <http://crowbar.sync.in/crowbar-repos>.  It also must
>> > include removing unused cruft which currently achieves nothing
>> > except confusing people :)
>> >
>> > > That aligns with other discussions that generally say "thank
>> > > goodness, yes!"  Anyone have objections or issues?
>> >
>> > I wouldn't be keen on seeing a new org until I'm clear about the
>> > answers to the above questions.
>>
>> _______________________________________________
>> Crowbar mailing list
>> Crowbar@dell.com
>> https://lists.us.dell.com/mailman/listinfo/crowbar
>> For more information: http://crowbar.github.com/
>>
>
>
>
> --
> Judd Maltin
> T: 917-882-1270
> F: 501-694-7809
> what could possibly go wrong?
>
>
>


-- 
Judd Maltin
T: 917-882-1270
F: 501-694-7809
what could possibly go wrong?
_______________________________________________
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/

Reply via email to